16장. 외부 개발 루프

출처 — 진 킴·스티브 예기, 『바이브 코딩 프로덕션의 원칙』(제이펍), 16장 (pp. 358~401). 원문 PDF vibe_coding_final_v11_260913.pdf (2026-09-13 판)

초·분(내부 루프)과 시간·날(중간 루프)을 벗어나 수주~수개월 단위로 시야를 넓히는 마지막 루프 — API라는 다리를 불태우지 않고, 워크스페이스 충돌과 브랜치 유실이라는 재앙을 예방·감지·교정하며, 조직 규모에서도 FAAFO를 지키는 법을 다룬다.

학습 목표

이 장을 끝내면 다음을 할 수 있다.

• API 파손이 하위 호환성 계약 위반인 이유와, 코드 축적·코드 파괴 두 철학의 차이를 설명한다.
• 워크스페이스 충돌(스튜나미)을 막는 세 가지 핵심 전략을 프로젝트에 적용한다.
• 위험도×기술 숙련도 매트릭스로 프로젝트에 맞는 검증 전략(블랙박스·화이트박스)을 선택한다.
• 검증(verification)과 검정(validation)의 차이를 구분하고, AI를 프로덕트 코파일럿으로 활용하는 방법을 설명한다.
• 브랜치 관리 실패가 부르는 재난을 예방하는 실천 원칙을 구현하고, AI 기반 CI/CD 도입의 비용 트레이드오프를 판단한다.

전체 흐름도

              §1  예방 — 외부 루프의 첫 번째 기둥
        수주~수개월 단위, 한 번의 실수가 조직 전체로 번진다
                          │
                          ▼
   §2  AI가 다리를 불태우게 두지 말기 ──▶ §3  API 보존 철학
   API 파손은 사보타주다               코드 축적(클로저·리눅스) vs 코드 파괴(스칼라)
                          │
                          ▼
   §4  스튜나미 피하기 ──▶ §5  최소화하고 모듈화하기
   워크스페이스 충돌·머지 재앙          최소주의 5원칙 + 모듈성 4원칙
                          │
                          ▼
   §6  에이전트 함대 관리하기 ──▶ §7  주방 안팎으로 감사하기
   2→4 에이전트, 복잡성은 기하급수적    위험×숙련도 매트릭스(표 16.1)
                          │
                          ▼
   §8  내면의 프로덕트 매니저 불러내기 ──▶ §9  빠르고, 야심 차고, 즐겁게 운영하기
   검증(verification) vs 검정(validation)   텔레메트리 — 사후 대응을 예방으로
                          │
                          ▼
              §10  감지 — AI가 모든 것을 내던져버릴 때
        스티브의 4만 파일 삭제 사고 → 브랜치 쓰레기 투기 6원칙
                          │
                          ▼
              §11  AI 시대의 CI/CD
        보안 검토·가이드라인 집행·에러 해석을 AI에 맡기되 비용은 통제한다
                          │
                          ▼
              §12  교정 — 스티브의 참혹하면서도 장대한 머지 복구 이야기
        표준 절차가 실패하면 목표만 주고 전략은 AI에게 맡긴다
                          │
                          ▼
              §13  끔찍한 프로세스와 아키텍처에 발목이 잡혔을 때
        모건 스탠리 — 데이터로 관료주의를 해체하다
                          │
                          ▼
              §14  결론 — 외부 루프의 8대 핵심 원칙 → 4부(17장)로

0. 용어 사전

참고 — 위쪽 5개는 이 장을 읽기 전에 알아야 하는 선행 용어다. 낯설면 해당 장을 먼저 보라.

1. 예방 — 외부 루프의 첫 번째 기둥

이 장은 분·일 단위로 분주하게 돌아가는 주방을 벗어나 시야를 넓힌다. 개별 요리를 만드는 단계에서 나아가, 수주·수개월을 투자해야 하는 메뉴와 공급망 설계를 다루는 것이 외부 루프다. 헤드 셰프가 재료 조달·주방 배치·인력 배치 최적화를 위해 조리 라인에서 물러나듯, 이 장은 AI 수셰프들을 지휘해 시스템을 구축하고 워크플로를 자동화하며 장기적으로 인프라를 강화하는 법을 다룬다.

외부 루프도 내부 및 중간 루프처럼 예방, 감지, 교정이라는 세 기둥을 중심으로 전개된다. 작업 공간 충돌로 인한 스튜나미를 어떻게 사전에 막을 것인지, 내부 API를 변경하지 말아야 하는 이유를 어떻게 설득할 것인지, CI/CD 파이프라인에 더 많은 안전망을 어떻게 구축할 것인지를 다룬다.

단일 주방에서 레스토랑 제국으로 확장하려면, 운영상의 문제가 조직 전반으로 퍼지는 것을 막는 안전장치가 필요하다. 외부 루프의 시간 단위는 수주~수개월이며, 이런 긴 시간 단위에선 단 한 번의 실수도 이해관계자 모두에게 광범위한 혼란을 초래할 수 있다. 예방 절에서는 가장 큰 위험인 API 파손을 시작으로, 여러 에이전트가 수주 동안 진행한 작업을 날려버릴 수 있는 작업 공간 충돌, 모듈식 아키텍처를 무너뜨리는 AI의 경향을 제어하는 최소화·모듈화, 늘어나는 에이전트를 조율하는 에이전트 함대 관리, 프로젝트 위험도에 맞춘 감사, 그리고 AI를 프로덕트 감각의 지렛대로 쓰는 법과 텔레메트리 운영까지 차례로 살펴본다.

시스템 수준의 설계에서는 이 장에서 배울 설계 원칙들을 항상 최우선으로 두고 매주, 경우에 따라서는 매일 검토해야 한다. 외부 루프 예방법은 지속 가능한 확장과 화려한 조직 실패를 가르는 요소이며, 엔터프라이즈 규모에서 FAAFO를 달성하는 데 필수적이다.

2. AI가 다리를 불태우게 두지 말기 — API 파손이라는 배신

모든 손님이 화가 나 있다. 모두가 사랑하던 대표 메뉴가 사라지고, 낯설고 구미가 당기지 않는 요리로 메뉴가 리뉴얼되어 있다. 알고 보니 수셰프가 새로운 요리를 실험하는 과정에서 메뉴 자체를 바꿔버린 것이다.

API는 서로 다른 소프트웨어 구성 요소 사이의 디지털 계약이다. 코드가 데이터베이스·서비스·라이브러리·다른 시스템과 대화하는 방식이 바로 API다. 모든 계약이 그렇듯, 예고 없이 조건을 바꾸면 반드시 결과가 발생한다. 다른 시스템이 의존하고 있는 API를 수정하거나 제거하는 순간 약속을 어기는 것이고, 그 계약에 기대고 있던 모든 구성 요소는 허둥지둥 적응해야 하는 상황에 놓인다. 사전 경고 없이 계약을 변경하면 이를 쓰는 모든 서비스·스크립트·모바일 앱이 깨진다. 결제는 실패하고, 새벽 2시에 호출기와 알림이 울리기 시작한다. API 파손은 클라우드 스케일에서 벌어지는 사보타주다.

이런 일은 실제 소프트웨어 세계에서 끊임없이 일어난다. API는 종종 사용 중단(deprecated)되거나 제거되고, 그로 인해 API를 호출하던 클라이언트가 깨지며 고객을 잃는 사태가 벌어진다. 스티브는 2020년에 「Dear Google Cloud: Your Deprecation Policy Is Killing You」라는 글에서 이 현상을 지적하며 분노 섞인 비판을 쏟아냈고, 상당한 주목을 받았지만 실제 변화는 거의 없었다. 이런 사용 중단과 파손은 API·라이브러리 차원만이 아니라, 사용자에게 직접 노출되는 기능에서도 동일하게 발생한다.

진의 워크벤치 롤백 사례. 진은 작가용 워크벤치 툴을 개발하던 중 같은 문제를 직접 겪었다. 코드베이스를 정리한 뒤 초안 순위를 매기는 과정을 더 빠르게 하려다 일련의 변경을 가했는데, 프로그램이 다시 깨지고 말았다. 진은 롤백 대신 앞으로 나아가며 고치는 전략을 택해, 고작 이틀 된 '레거시' 기능을 복구하는 데 두 시간 넘게 쏟아부어야 했다. AI는 기존 인터페이스를 모두 우회하는 코드를 작성했고, 인터페이스가 바뀌고 함수 인자가 추가·변경되었으며, 수십 개의 새로운 진입점이 생기고 딕셔너리 키 이름까지 바뀌었다. 코드베이스가 얼마나 심각하게 망가졌는지 깨달은 진은 결국 롤백을 선택했다. 그리고 처음부터 다시 시작하며 AI에게 "기존 기능은 어떤 것도 깨뜨리면 안 된다"라는 단 한 문장을 추가하고, 완전히 망가진 버전의 깃 커밋 해시를 함께 제공했다. 10분 뒤 진은 새로운 접근 방식이 거의 구현된 새 버전을 얻었고, 동시에 기존 버전도 '프로덕션'에서 계속 쓸 수 있는 상태로 유지할 수 있었다.

별도의 공간에서 새로운 함수나 API를 만드는 것은 과도한 작업이 아니다. 격리된 공간은 훌륭한 가드레일 역할을 한다 — 검증된 레시피를 건드리지 않으면서 새 레시피를 테스트하는 것이기 때문에 애플리케이션은 안정성을 유지한다. FAAFO의 옵셔널리티는 언제나 하나의 길만 선택할 필요는 없다는 사실을 일깨워준다. 여러 버전을 동시에 지원하면 안정성을 희생하지 않으면서도 모두를 만족시킬 수 있다.

3. API 보존 철학 — 코드 축적 대 코드 파괴

API 보존 철학이 어떤 모습인지는 대비되는 두 패턴으로 이해할 수 있다 — 코드 축적(code accretion)과 코드 파괴(code destruction)다.

저자들이 인용한 코드 생존율 그래프(그림 16.1, 출처: Rich Hickey, "A History of Clojure", Proceedings of the ACM on Programming Languages Vol. 4)는 클로저(Clojure)·리눅스·스칼라(Scala) 세 프로젝트를 비교한다. 클로저와 리눅스는 보수적인 API 철학을 채택해 API가 바뀌지 않아야 한다는 원칙을 실천한다 — 그래프에서 삭제되는 코드의 양이 매우 적고, 10년 전에 작성된 코드 대부분이 오늘날까지 남아 있다. 그래서 10년 전 클로저·리눅스 프로그램이 지금도 여전히 동작한다. 이맥스도 함수·API가 때때로 사용 중단되긴 하지만 동작은 계속 유지되며 실제 제거는 거의 없어, 비슷한 양상일 것으로 저자들은 추측한다.

반면 스칼라 코드베이스는 대규모 코드 파괴가 기본 철학임을 보여준다 — 초기 코드의 거의 대부분이 오늘날까지 살아남지 못했다. 오래된 스칼라 프로그램이 더 이상 컴파일되지 않는 이유는, 의존하던 스칼라 컴파일러 코드 자체가 사라졌기 때문이다. 스칼라는 사람들이 의존하는 기능들을 정기적으로 사용 중단시키고 삭제한다. 안타깝게도 이런 일은 업계 전반에서 비일비재하다 — 젯브레인즈도 대표적인 사례로 꼽힌다. 많은 팀이 API의 하위 호환성 유지를 부담으로 여겨 발생하는 현상이다.

이 그래프가 전하는 메시지는 하나다 — AI가 기존 동작을 손상시키거나 변경하지 않은 채 코드를 추가하도록 신경 써야 한다. 클로저 그래프처럼 만들어야 하고, AI가 스칼라 그래프처럼 기존 코드(또는 테스트)를 변경·삭제하게 해서는 안 된다. 그래프에서 수평으로 유지되는 구간은 순항(코드가 영속적으로 산다는 뜻)을, 울퉁불퉁하게 아래로 꺾이는 구간은 코드가 삭제되고 그에 의존하던 기능·소비자가 함께 깨지는 상황을 나타낸다.

API 계약을 얼마나 충실히 지키느냐는 시간이 지날수록 사용자 기반을 키울지, 사용자들을 소외시킬지를 좌우하는 결정적 요인이다. 하위 호환성을 신경 쓰지 않는 개발자들은 "유지 보수를 하려면 너무 많은 일을 해야 한다"는 변명으로 합리화한다. AI가 등장했으니, 이 변명은 이제 명예롭게 은퇴시켜야 한다.

4. 스튜나미 피하기 — 작업 공간 충돌 방지

유난히 바쁜 어느 날, 한쪽에선 스튜를 준비하고 다른 쪽에선 수플레를 준비하던 두 사람의 작업대가 어느 순간 교차해버려 수플레 반죽이 끓는 스튜 냄비에 그대로 들어간다. 스튜가 용암처럼 솟구치며 '스튜나미'가 주방을 덮친다.

코딩 에이전트를 쓸 때도 주의를 기울이지 않으면 이와 유사한 대규모 재앙이 벌어질 수 있다. 여러 에이전트를 함께 쓰면서 새롭게 발견되는 문제 — 대규모 프로젝트에서의 워크스페이스 혼란이 그것이다. 큰 규모에서 코딩 에이전트는 워크스페이스를 제대로 인지하지 못하면 잘못된 디렉터리, 잘못된 브랜치, 심지어 잘못된 저장소에서 몇 시간 또는 며칠 동안 작업할 수 있다.

프로덕션 운영 경험이 있는 엔지니어 상당수는 터미널 창에 서로 다른 색상을 쓴다 — 빨간색은 프로덕션(절대 재부팅 금지), 초록색은 스테이징(마음껏 재부팅). 여기서 말하는 워크스페이스는 간접 참조가 존재하는 모든 장소를 포함한다 — 디렉터리, 리포지터리, 브랜치, 데이터베이스, API 엔드포인트 등이다.

스티브의 모노레포 중첩 사고. 스티브는 워크스페이스 세팅을 잘못해 불과 몇 주 사이에 세 번이나 대형 사고를 냈다. 와이번 프로젝트의 메인 프로젝트(자바) 안에 타입스크립트 클라이언트 리포지터리를 모노레포처럼 중첩시켜두었는데, 결국 스튜나미로 이어졌다. 스티브는 스택도 폴더도 다르니 구획이 명확히 나뉜 주방에서 요리하듯 에이전트도 잘 처리할 거라 생각했지만, AI에겐 그저 코드 덩어리였다. 너무 늦게야 타입스크립트 전용 리포지터리 안에 자바 프로젝트 복제본이 생긴 것을 발견했고, 무슨 일이 벌어졌는지 파악하는 데 하루를 썼다. 결국 타입스크립트 리포지터리를 삭제하고 처음부터 다시 시작하는 편이 나을 정도였다.

개발자 한 명이 프로젝트 2개, 에이전트 2개를 다룰 때도 이런 혼란이 발생하는데, 개발자 50명이 각자 5개의 에이전트를 쓰면 어떤 일이 벌어질지 상상해보자. 저자들은 실제로 50명이 3일 동안 모여 코드 병합 처리만 할 수밖에 없었던 사례를 들었다고 전한다.

세 가지 핵심 전략은 다음과 같다.

첫째, 워크스페이스(그리고 작업)를 명확하게 분리한다. 여러 에이전트가 서로 간섭할 가능성이 있는 모든 작업 공간(디렉터리·리포지터리·브랜치)을 가능한 한 다르게 배정한다. 보안 목적으로 샌드박스 안에서만 작업하게 할 수도 있다 — "이 서브디렉터리 밖은 절대 접근할 수 없고, 할당된 브랜치 외에서는 수정하지 마세요" 같은 명예 시스템, 또는 더 안전하게는 도커 컨테이너 같은 완전히 격리된 환경이다.

둘째, 모든 것에 명시적으로 이름을 붙인다. 현재 어떤 워크스페이스에 있는지 한눈에 알 수 있게 이름 규칙을 표준화한다. 브랜치 이름에 에이전트 이름이나 작업 이름을 반드시 포함시키고, 터미널 창의 배경 색을 다르게 하되 일관성을 유지한다. OpenAI 코덱스도 codex:refactor-ranking 같은 형식의 브랜치 이름을 자동 생성해 이 원칙을 실천한다.

셋째, 가능하다면 단순화한다. 스티브는 서버와 클라이언트를 별도 리포지터리로 분리하고 싶었지만, 클로드가 덜 혼란스러워하도록 하나로 병합했다. settings.gradle에 설정해두었던 그레이들 모듈 이름 재매핑 코드도, 테스트 실행 시 클로드가 매번 혼란스러워해 제거했다.

세 전략 모두 외부 루프에서의 설정이 필요하다 — 미리 구조를 설계하고 사고 예방 장치(표지판·가드레일)를 깔아두어야 한다. 작업이 실제 일어나는 중간 루프에선 직접 세운 표지판을 계속 확인하면 된다. AI 코딩이 대중화될수록 상당한 사고가 발생할 것이고, 사고 전 경고 신호는 분명히 있지만 직접 세워둔 신호대만 보인다. 명확한 경계 없이 작업하는 것은 스스로 주방에 가장 위험한 문제를 초대하는 것과 같다.

5. 최소화하고 모듈화하기

수셰프에게 커피 한 잔을 부탁했더니, 돌아와 보니 주방 조리대와 커피머신이 합쳐져 있고 급수관은 알 수 없는 선과 얽혀 있다. 커피 맛은 괜찮았지만 커피머신을 옮기거나 교체하려면 조리대와 수도관을 모두 파괴해야 한다. AI를 최소주의와 모듈성 쪽으로 이끌지 않으면 코드베이스에 이런 일이 생긴다.

책은 이미 이런 사례를 소개했다 — 4장 §2.2(엘드리치 호러 코드베이스 — FAAFO가 죽을 때)의 진의 워크벤치처럼. 스티브도 비슷한 일을 겪었다 — 간단한 스피너 UI를 요청했는데 AI는 몇 개의 메서드면 충분할 일을 이해하기 어려운 수많은 메서드로 구현했다. 테스트를 하나 요청하면 실제 프로덕션 환경과 비슷하게 작업하겠다는 장담과 함께, 애플리케이션 전체보다 더 큰 수천 줄의 모의 인프라 코드를 생성하기도 했다.

AI는 장황하게 작업하려는 경향이 있고, 이 경향은 문제를 눈덩이처럼 불린다. 코드엔 관성이 있어, 비대해진 코드는 사람뿐 아니라 AI에게도 모든 것을 어렵게 만든다. 10장 §4(콘텍스트 포화의 위험성)에서 다뤘듯 콘텍스트 윈도의 한계 때문에 AI 모델은 대규모 코드베이스에서 어려움을 겪는데, 코드베이스는 비대해질수록 하향 나선을 그리며 AI가 점점 손댈 수 없는 구렁텅이로 빠진다.

AI가 이미 정립된 모듈 인터페이스를 우회하며 모듈 경계를 파괴하면 더 안 좋아진다. 논리적으로 분리되어 있던 모듈이 하나로 얽히기 시작하면 변경이나 테스트가 불가능해진다. 원래라면 별도로 개발·유지 보수가 가능했던 두 모듈을 융합하는 순간, FAAFO의 옵셔널리티뿐 아니라 빠름과 재미까지 함께 깨진다.

모듈 경계를 강제하는 수단에는 최소주의와 모듈성 두 범주가 있다.

최소주의 팁

• 새롭게 추가될 때마다 의심한다 — 새 라이브러리, 새 파일까지도 진짜 필요한지 AI에게 물어보고, 기존 구조 내에서 구현할 수 있었던 건 아닌지 AI가 자신의 선택을 정당화하게 한다.
• 코드 예산을 설정한다 — 몇 줄 이내에서 작업하라고 명시하거나 최소한만 변경하라고 지시한다. 제약 조건은 AI가 그 안에서 사고하게 만든다.
• 선구현, 후리팩터링 패턴을 따른다 — 먼저 초벌 기능을 만들게 한 후, 간결성·가독성·우아함을 기준으로 한 리팩터링은 별도 단계로 지시한다.
• 불필요한 의존성을 금지한다 — 승인 없이 새 라이브러리·프레임워크를 끌어들이지 말고, 가능하면 기존 도구나 표준 라이브러리 함수로 작업을 완료하게 한다.
• 외과 수술처럼 정밀하게 커밋하라고 요구한다 — 목표 달성을 위한 최소한의 변경만 진행하게 하고, 관련 없는 경로나 모듈을 건드리면 거부한다.

모듈성 팁

• 모듈 경계를 명확히 정의한다 — 각 작업마다 AI가 수정할 수 있는 모듈과 수정할 수 없는 모듈을 명시적으로 지정한다. 명예 시스템을 쓰거나 환경 자체를 격리해 강제한다.
• 인터페이스 불변성을 강제한다 — 명시적으로 요청하고 승인하지 않는 한 기존 모듈 인터페이스는 신성불가침이라고 지시한다(AGENTS.md 파일에 추가해도 된다).
• diff 리뷰로 확산적 코드 작성을 감시한다 — 국소적 변경으로 해결할 수 있는 작업인데 AI가 수많은 파일을 건드리고 있다면 특히 경계한다.
• 정기적으로 아키텍처 감사를 한다 — 필요하면 AI의 도움을 받아 커플링 정도를 검토하고, 모듈 독립성을 높일 기회를 미리 알아챈다.

코드 크기를 최소화하고 모듈성을 극대화하는 습관은 코드베이스의 무결성을 보호한다. 무결성이 확보된 코드베이스에선 AI로 개발 속도를 가속하더라도 적응 가능하고 유지 보수 가능한 소프트웨어를 만들 수 있다 — 당연히 FAAFO 달성에도 효과적이다.

6. 에이전트 함대 관리하기

머지않아 활기차게 움직이는 AI 어시스턴트 함대를 관리하게 될 것이다. 보조 인력 한 명과 요리하다가, 만석인 레스토랑 체인의 주방 브리게이드 시스템을 운영하는 것과 같다. 4개 이상의 AI가 각자 다른 작업을 수행하기 시작하면, 단순한 기억력만으로는 서비스를 유지하지 못한다는 것을 깨닫는다.

스티브의 2→4 에이전트 실험. 스티브는 도구 없이 에이전트 2개를 돌리다가 4개로 늘리면서 인지 부하가 폭발적으로 증가해 터미널 관리가 불가능해지는 걸 경험했다. 4개의 서로 다른 에이전트가 4개의 터미널에서 동시에 돌아가자 어떤 에이전트가 어떤 터미널과 연동되어 있는지 헷갈리기 시작했고, 작업을 놓치는 일이 빈번해졌다. "4개의 에이전트가 각각 무엇을 하고 있는지 기억할 수가 없었다"고 스티브는 회상한다.

스티브는 이 문제를 해결하려 중앙 지휘소를 만들었다. 먼저 각 에이전트에 '버그' 에이전트, '타입스크립트 클라이언트' 에이전트, '이맥스' 에이전트처럼 고유한 역할을 부여해 고유한 작업 스트림을 갖게 했다. 그런 다음 에이전트 각각의 상태를 추적하는 전용 문서를 만들었다 — 현재 프롬프트, 작업 큐, 사용 중인 브랜치, 상태를 기록하는 이 문서가 주방의 클립보드 역할을 하며 작업 흐름 조율의 핵심 도구가 되었다(에스코피에가 정립한 주방 브리게이드 시스템은 17장 §5가 더 다룬다).

스티브는 에이전트를 2개에서 4개로 늘리면 생산성이 2배가 될 거라 생각했지만, 복잡성은 선형이 아니라 기하급수적으로 증가했다 — 조직화에 필요한 작업이 10배 이상 늘어난다는 것을 몸소 체험했다. 조율 시스템 구축 전에는 하루에 몇 시간이나 디렉터리 구조를 정리하고, 여러 리포지터리를 설정하고, 모니터링용 터미널을 세팅하는 자신을 발견하곤 했다. 구축 후에는 터미널 창 정리, 머지 수행, 조율용 문서 작성, 콘텍스트 공유 수단 확보 등을 시스템으로 해결할 수 있었다.

코딩 에이전트는 초기 단계의 기술이라 여러 에이전트를 병렬 관리하는 데는 많은 노력이 필요하다. 흥미롭게도 스티브는 약 3주간 '영원히 결별했다'고 생각했던 이맥스를 다시 쓰기 시작했다 — 콘텍스트 계획 문서와 작업 설명 문서를 관리하기 좋았고, 여러 터미널 세션을 동시에 관리하기에도 유용해 중심 교차로 역할을 해줬기 때문이다. 저자들은 이 책이 출간될 즈음에는 워크스페이스 멀티태스킹을 직접 도와주는 도구들이 10개 이상 등장해 있을 것으로 예상했다.

7. 주방 안팎으로 감사하기 — 위험×숙련도 매트릭스

사이먼 윌리슨이 Go를 잘 알지도 못한 채 Go 서비스를 운영한다는 이야기를 읽으면 '무모하다'고 여길 수 있다. 하지만 저자들은 특정 언어 전문가가 아닌 사람도 그 코드가 의도한 대로 작동하는지 검증할 수 있다고 본다 — 실제 감사 전문가들이 해온 일이다.

바이브 코딩으로 만든 코드를 풀 리퀘스트로 제출하기 전, 감사 전문가처럼 AI 어시스턴트의 작업을 철저히 점검해야 한다. 검토의 깊이는 프로젝트의 위험 수준과 해당 언어에 대한 친숙도에 비례해야 한다.

블랙박스 테스트는 코드는 보지 않고 입력·출력만 살펴보는 방식이다. 출력이 합리적이면 배포한다 — 해당 기술을 알든 모르든, 저위험 프로젝트에서는 타당한 접근이다. 화이트박스 테스트는 코드 내부를 검사한다 — 실행 경로를 추적하고, 에지 케이스를 식별하고, 데이터 구조와 비공개 구현 세부 사항을 연구하고, 단일 장애점(SPOF)까지 찾아낸다. 고위험·고영향 프로젝트에서는 이 정도로 정밀하게 감사해야 한다. 코드는 AI가 작성했을지라도 그 책임은 여전히 사람에게 있다.

표 16.1 바이브 코딩 테스팅 전략(위험도×숙련도 매트릭스)

표의 한 축은 프로젝트의 위험도(토이·취미 프로젝트부터 임무 수행에 꼭 필요한 프로덕션 서비스까지)를, 다른 한 축은 해당 기술(언어·프레임워크·런타임·클라우드 서비스)에 대한 숙련도를 나타낸다.

고위험, 기술을 잘 아는 경우. 익숙한 기술(진에게는 클로저, 스티브에게는 코틀린)로 핵심 시스템을 개발하는 경우다. 강도 높은 화이트박스 테스트로 경쟁 상태나 검증되지 않은 에지 케이스를 찾아내고, 동시에 전방위적인 블랙박스 테스트도 병행한다 — 레시피를 잘 아는 7코스 요리를 모두 맛보며 어긋난 부분이 없는지 확인하는 것과 같다. 진의 작가용 워크벤치 툴과 스티브의 와이번 서버·게임 클라이언트가 이 사분면에 해당한다.

고위험, 기술을 잘 모르는 경우. 가장 도전적인 사분면이다 — 스티브의 와이번 타입스크립트 클라이언트 개발이 그 예다. 4개의 서로 다른 코드베이스를 대체할 수 있다는 잠재적 보상 때문에 위험을 감수할 가치가 있다고 판단했다. 이 사분면은 다층적 접근이 필요하다 — ① 블랙박스 테스트에 크게 투자한다: 다양한 조건에서 시스템이 올바르게 작동하는지 검증하는 명세서와 포괄적인 테스트 스위트를 만든다. ② 상대적으로 가볍게 화이트박스 테스트를 한다: 러스트의 소유권 모델이나 Go의 동시성 패턴을 몰라도 deleteAllData()라는 함수가 존재해서는 안 된다는 정도는 알 수 있고, 5개 파일이면 충분한데 AI가 수백 개 파일을 만들면 그 자체가 위험 신호다. ③ AI를 코드 리뷰어이자 화이트박스 감사 전문가로 활용한다: 왜 그렇게 구현했는지 설명하게 하고, 잠재적 에지 케이스 식별을 요구하고, 자신의 작업을 스스로 비판하게 한다. 익숙하지 않은 기술을 써도 강력한 테스트와 신중한 감사가 있다면 FAAFO의 문은 여전히 열려 있다.

저위험, 기술을 잘 아는 경우. 익숙한 기술로 사이드 프로젝트를 진행한다면, 빠르게 성장할 것이라 확신하지 않는 한 가벼운 화이트박스·블랙박스 테스트만으로 충분하다. 코드를 한 번 훑어보고 간단한 스모크 테스트 몇 개를 작성하는 정도면 된다. 진의 트렐로 리서치 자동화 도구가 이 사분면에 속한다.

저위험, 기술을 잘 모르는 경우. 생소한 언어로 작은 데이터 분석 유틸리티를 작성하는 경우다 — 입력·출력 데이터의 형태를 알고 있다면 순수한 블랙박스 감사만으로 충분하다. 커피 원두가 분쇄기를 통과하기 전·후 무게를 재서 수치가 일치하면 기계를 열어보지 않아도 되는 것과 같다. 이 사분면이 전형적인 바이브 코딩 스타일이다 — 내부 구현체에 의도적으로 무지한 채, 지수적 확장을 받아들이고 원초적인 판단에 프로젝트를 맡긴다. 위험이 낮게 유지되는 동안은 재미있게 작업할 수 있지만, 프로젝트가 성공하며 위험이 커지면 빠져 있던 테스트 때문에 괴로워질 수 있다. 스티브가 진행 중인 와이번 테스트 재작성 작업이 정확히 이 사분면에 위치한다 — 새로 작성하는 코드가 모두 테스트 코드이고 구현은 아니므로 무언가를 깨뜨릴 가능성이 낮은 저위험 작업이다.

이 사분면에 머물러야 할 때. 스티브는 10년간 써온 스포크(Spock) 테스트 프레임워크를 떠나 코틀린 기반 프레임워크로 이전하면서, 새 프레임워크도 기존 프레임워크도 깊이 알지 못한 채 의도적으로 피상적인 학습만 선택했다 — 세부 사항은 AI가 관리해줄 수 있다고 봤기 때문이다. 스티브가 신경 쓰는 것은 프레임워크 내부의 setup()·teardown() 동작이 아니라 테스트 그 자체였고, "마법 같은 일이 덜 일어나는" 프레임워크로 옮기면 AI 어시스턴트도 덜 헷갈릴 것이라 판단했다. 기존 테스트와 새 테스트를 나란히 실행하며 마이그레이션을 진행해 위험은 낮추고 선택지는 늘렸다. 진도 25년간 SPSS로 통계 분석을 하다가 구글 코랩에서 파이썬 노트북으로 클러스터 분석을 수행한 사례가 있다 — 익숙한 데이터로 작업했기에 블랙박스 검증만으로 신뢰 여부를 결정할 수 있었다.

반대로 온라인 경매 사이트의 정산 프로세스처럼 복잡한 문제를 이 사분면에 머물며 다루는 것은 잘못된 선택이다 — 이 경우엔 복잡한 UI 로직까지도 단위 테스트가 필요할 정도로 모든 종류의 테스트를 동원해야 한다. 진의 트렐로 프런트엔드 애플리케이션도 처음엔 저위험·저숙련에서 시작했지만 나중엔 고위험·저숙련 사분면으로 옮겨갈 수밖에 없었다.

저자들의 조언은 이렇다 — 위험도·숙련도와 무관하게 항상 최소한의 블랙박스 테스트는 한다. 러스트나 REST를 잘 몰라도 코드에 심각하게 잘못된 부분이 있으면 알아볼 능력은 있고, AI에 검증을 의지해도 된다. 고위험 애플리케이션에서는 블랙박스 테스트에 화이트박스 테스트의 엄격함을 더해 균형을 맞추고, 시작과 끝의 숫자를 맞추는 것뿐 아니라 치명적인 오류까지 확인해야 한다.

8. 내면의 프로덕트 매니저 불러내기 — 검증과 검정

책 전반에서 검증(verification) — "요구 사항대로 제대로 만들어졌는가?"를 확인하는 절차 — 을 다뤄왔다. 테스트 자동화·린터·정적 분석 도구가 이 질문에 답한다. 그에 못지않게, 어쩌면 더 중요한 절차가 검정(validation)이다 — "우리가 올바른 제품을 만들고 있는가?"라는 질문을 확인하는 단계다. 전통적으로 이 나침반은 프로덕트 매니저(PM)가 쥐고 있었지만, PM은 회사에서 가장 희소한 자원 중 하나라 하루 24시간 회의에 들어가 있기 일쑤고, 모든 프로젝트에 배정되지도 않는다.

바이브 코딩에서는 이 나침반을 AI 수셰프에게 맡길 수 있다. AI는 시장조사와 사용자 인사이트를 다루는 전공자처럼 행동해, 인간 PM의 답변을 기다리지 않고도 계속 전진할 수 있게 해준다. 이 작업을 충분히 준비한 다음 훈련된 PM에게 가져가 전문가 리뷰를 받으면 된다.

바이브 코딩과 함께라면 기술자의 관점에서 벗어나 전략가의 관점으로 프로젝트를 볼 시간이 생긴다 — 노력이 사용자를 만족시키고 목표를 달성하는 데 투입되는지 점검할 수 있다. AI는 이 지점에서 프로덕트 코파일럿이라는 새로운 역할을 맡는다 — 1인 개발자나 소규모 팀에서 사실상 PM 역할을 해왔던 사람에게, '어떻게'에 깊이 빠지기 전에 '왜'와 '무엇을' 먼저 생각하게 도와주는 주니어 PM이 상시 대기하는 셈이다.

여기엔 대칭성이 있다 — 프로덕트 오너와 UX 디자이너는 엔지니어 없이도 AI로 아이디어를 빠르게 프로토타이핑해 기술적 함의를 탐구할 수 있고, 반대로 엔지니어는 과중한 업무에 시달리는 PM을 기다리지 않고도 제품 인사이트를 얻을 수 있다. 이렇게 상호적으로 권한을 부여하면 모두가 더 큰 자율성을 확보한다 — 자율성은 3장 §4(자율성)가 다룬 "조율 비용"·"마음 읽기 비용"을 AI 어시스턴트와 함께라면 직접적으로 줄일 수 있다는 뜻이기도 하다.

진의 워크벤치 툴 사례가 검정이 개발을 이끈 대표적인 예다 — AI는 진이 어떤 랭킹 알고리즘을 채택할지 고민할 때, 알고리즘보다 랭킹 프로세스의 속도를 개선하는 것이 더 중요하다는 점을 깨닫도록 도왔다(NK/t에서 t를 줄이는 것이 중요하다는 상기).

AI 코파일럿이 해줄 수 있는 일은 다음과 같다.

• 고객 지원 티켓·리뷰·소셜 게시글 등 방대한 피드백을 훑어 반복적으로 나타나는 문제점과 요청 많은 기능을 찾아낸다.
• 경쟁사 기능·시장 포지셔닝·고객 리뷰를 분석해 차별점을 찾게 돕는다.
• 막연한 아이디어를 인수 기준과 에지 케이스를 담은 구체적인 유저 스토리로 전환한다.
• A/B 테스트나 실험을 브레인스토밍하고 개요를 잡아 핵심 가정을 검증할 수 있게 한다.
• 새 영역의 시장 규모·잠재력을 빠르게 파악해 니치한 취향인지 게임 체인저인지 가늠하게 돕는다.
• 도달 범위·영향도·공수 관점에서 백로그를 검토해 고부가가치 기능을 찾아준다.
• 고객 여정 지도를 그려 마찰 지점과 아하 모멘트를 식별한다.
• 숙련된 PM이라면 던졌을 '만약 이렇다면?' 같은 까다로운 질문을 대신 제기해 숨겨진 요구 사항을 드러낸다.

제품 발견과 검정 프로세스에 AI를 활용하면, 원래는 PM의 시간을 들일 가치가 없었을 의사결정에까지 전문성을 끌어올 수 있다. 그 결과 더 자율적으로 행동할 수 있고, 작성하는 코드가 사용자의 실제 문제를 해결하고 있음을 더 잘 보장할 수 있다.

9. 빠르고, 야심 차고, 즐겁게 운영하기 — 텔레메트리

AI 수셰프들이 모든 오븐·스토브·팬트리 선반에 실시간 텔레메트리와 대시보드를 연결해두면, 요리가 타고 있는지 확인하려 분주히 돌아다닐 필요가 없다. 오븐 과열과 재고 소진을 실시간으로 보고받는다.

AI가 텔레메트리를 자동으로 모니터링하게 세팅해두면, 몇 시간의 화재 진압을 몇 분의 문제 탐지로 예방할 수 있다. 진은 수년 전, 수만 켤레의 운동화를 몇 시간 안에 판매해야 하는 대규모 신발 출시 이벤트 개발에 참여했는데, 이벤트 도중 주문 파이프라인이 깨지는 참사가 벌어졌다. 엔지니어들이 자바 스택 트레이스와 로그 파일을 들여다보며 원인을 찾았는데, 외부 배송 옵션 서비스의 호출 제한(rate limit)이 문제였다 — 진단 시점엔 이미 대량의 주문 실패가 발생한 뒤였다.

약 20년 전, 제프 베이조스는 스티브를 포함한 약 20명의 직원을 자신의 집으로 초대해 "AI를 사용해 프로덕션 장애를 감지하고 가능하면 자동으로 수정하는 제품"이라는 아이디어를 브레인스토밍했다. 당시 기술로는 뒷받침할 수 없는 공상과학에 가까웠지만, 베이조스는 오늘날 우리가 절실히 필요로 하는 것 — AI를 텔레메트리 데이터에 직접 연결하는 것 — 을 정확히 예견하고 있었다.

텔레메트리는 사후 대응(troubleshooting)에만 쓸 필요가 없다 — 선제적 예방과 교정에도 쓸 수 있다. AI 에이전트에게 문제 징후를 포착하고 적절한 사람에게 알림을 주라고 지시해두면 고객의 분노 트윗을 기다릴 필요가 없다. 현존하는 AI 에이전트는 이미 대시보드에 접근할 수 있고, Puppeteer 같은 도구로 브라우저 상호작용을 시뮬레이션하며, 콘솔 로그를 확인하고 디버깅용 자바스크립트를 주입할 수도 있다.

훌륭한 운영 플레이북은 결국 단순한 패턴과 명확한 의사결정 트리로 귀결된다 — AI 에이전트는 이 레시피의 상당 부분을 대신 실행할 수 있다. MCP 같은 메커니즘으로 AI를 시스템과 연결해두면 인간 운영자보다 더 빠르게 진단·수정 작업을 진행한다. 저자들은 머지않아 AI가 자동으로 프로덕션 로그를 스캔하고, 의심스러운 영역을 식별하며, 관련 코드를 확인한 뒤 PR을 날릴 것이라 예상한다 — 지휘권은 여전히 사람에게 있겠지만, 장애가 났을 때 더 이상 혼자가 아니다. 업계는 이미 AI 기반 관측성(observability) 도구와 운영 특화 도구로 빠르게 나아가고 있다 — 인간이 쓰기 쉬운 UX보다, AI 에이전트가 데이터에 접근할 수 있게 설계하느냐가 승패를 가른다.

10. 감지 — AI가 모든 것을 내던져버릴 때

복잡한 시스템에서 여러 AI 에이전트를 오케스트레이션할 때는 문제의 파급 반경을 기준으로 감지 우선순위를 정해야 한다 — 가장 먼저 치명적인 데이터 손실, 그다음 시스템 전반의 파이프라인 모니터링(§11), 마지막으로 사소한 이상 신호를 경쟁 우위로 바꿔주는 조기 경보 시스템 순이다. AI 에이전트는 소리 소문 없이 저장소를 통째로 파괴할 수도 있다. 외부 루프 감지 역시 아키텍처를 설계하는 동안에도 실천법을 항상 의식하고, 안전망을 주 단위로 점검해야 한다.

스티브의 4만 파일 유실 사고. 스티브는 약 한 달 동안 Amp에 3000달러 이상을 써가며 와이번 게임의 TypeScript-Node.js 클라이언트를 처음부터 다시 작성하고 있었다 — 기존 안드로이드·iOS·플루터·스팀용 자바 클라이언트와 프로토타입 전부를 대체할 야심 찬 프로젝트였다. 어느 날 스티브는 AI 파트너가 파일을 볼 수 없다고 불평해 코드를 열어봤더니, 클라이언트 코드가 담긴 폴더가 전부 사라져 있었다 — 코드 1만 줄과 파일 4만 개가 통째로 사라졌고, 백업도 빗버킷 저장소의 흔적도 없었다.

문제의 원인은 코딩 에이전트가 만들어낸 혼란스러운 깃 브랜치 무더기였다. 스티브는 모든 변경 사항이 main 브랜치에 안전하게 병합되었다는 에이전트의 말을 곧이곧대로 믿고, 더 이상 필요 없어 보이는 브랜치들을 AI와 함께 정리했다. 알고 보니 일주일 동안 main 브랜치에 병합된 코드는 하나도 없었고, '불필요하다'고 여겨 정리한 브랜치들 안에 실제 코드가 들어 있었다. 결과적으로 스티브는 일주일 치 작업을 통째로 잃었고 3000달러는 증발했다.

몇 분간의 사투 끝에 스티브는 노드 서버를 실행 중이던 터미널 창 하나가 열려 있는 것을 발견했다 — 코드가 거기 그대로 있었다. 그 터미널 세션이 지구상에 남아 있던 마지막 소스 코드 사본을 간신히 붙잡고 있었던 것이다. 창을 닫거나 잠깐이라도 디렉터리를 벗어났다면 모든 파일은 영원히 사라졌을 것이다. 스티브는 조심스럽게 해당 디렉터리를 안전한 위치로 복사한 뒤, 신중하게 git add를 입력하고 긴급 상황이라 PR 형식은 신경 쓸 겨를도 없이 main 브랜치에 강제 푸시를 단행해 겨우 일주일 치 작업을 확보했다.

저자들은 이 사건을 브랜치 쓰레기 투기(branch litterbug)의 전형적인 사례로 본다 — AI가 마구잡이로 투기한 브랜치를 정리하는 과정에서 참사가 벌어진 것이다. 이 경험이 남긴 여섯 가지 교훈은 다음과 같다.

1. 항상 브랜치 의식하기. AI는 당신이 따라잡을 수 있는 속도보다 훨씬 빠르게 브랜치를 만든다. 중요한 작업이나 세션이 끝날 때마다 브랜치를 점검하고, 지워도 되는지 AI에게 조심스럽게 물은 뒤 그 제안을 다시 검증한다. AI가 임시 브랜치를 만들 때마다 그 이름을 작업 추적 문서에 기록하게 하고, 작업이 끝나면 상태를 '완료'로, 브랜치를 '삭제 예정'으로 표시하게 한다. 실제 삭제는 검토 후 직접 하거나 AI에게 시킨다. 브랜치 네이밍 규칙도 일관되게 정한다.
2. 내가 어디에 있는지 반드시 알기. AI가 어떤 브랜치·저장소를 건드리고 있는지 항상 파악해야 한다 — 저자들은 AI 코딩 툴 회사들에 브랜치를 UI에서 명확히 보여달라고 요청까지 했다.
3. 깃 제어는 당신의 책임이다. 깃 명령을 AI에게 맡기는 것은 또 하나의 위험 계층을 추가하는 일이다. 최소한의 신뢰가 쌓일 때까지는 git commit·git push·브랜치 관리는 손으로 직접 하는 편이 낫다.
4. 원격 저장소에 자주 푸시하기. 백업은 많을수록 좋다. 직접 깃 서버를 호스팅하고 있어도 가끔은 클라우드에 별도 스냅숏을 백업해둔다.
5. 정리 작업 중에는 특히 조심하기. 오래된 브랜치·디렉터리를 삭제할 때는 먼저 diff를 눈으로 확인하고, 소중한 무언가가 남아 있는지 점검한다.
6. 코드 리뷰는 최후의 안전망이다. AI가 생성한 커밋 메시지는 장황해 대충 훑고 넘어가고 싶은 유혹이 들지만, 그 안에 잘못된 경로·틀린 가정·브랜치 혼선 같은 단서가 숨어 있을 수 있다.

바이브 코딩은 속도·야심·자율성을 제공하지만 그 힘엔 반드시 규율이 따라야 한다 — 특히 버전 관리에는 늘 경계하는 태도가 필요하다. 진 역시 거의 10년 전 공항에서 실수로 강제 푸시를 해버려 main 브랜치를 날린 경험이 있다.

11. AI 시대의 CI/CD

세계 최고의 주방에는 '통제된 혼돈'이 존재한다 — 주방을 떠나기 전 모든 것은 시식 과정을 거친다. AI를 쓰는 순간 외부 개발자 루프의 일부인 CI/CD 파이프라인은 훨씬 더 중요해진다 — 즐겁게 기능을 배포하느냐, 광범위하게 식중독균을 뿌리느냐를 가른다.

데브옵스 연구가 밝혀낸 일관된 성공 원칙 하나는, CI/CD 파이프라인엔 모든 테스트가 통과되었음을 알려주는 피드백 루프가 필요하며 이 루프가 있어야 확신을 갖고 프로덕션에 배포할 수 있다는 것이다. 전통적 워크플로가 로컬 단위 테스트로 버그를 잡았다면, CI/CD 파이프라인은 통합 테스트로 더 복잡한 문제를 처리했다.

AI는 코드를 검토·분석·비판하는 데 탁월해, CI/CD 파이프라인을 단순 통과/실패 체크 이상으로 바꿀 수 있다.

• 보안 검토 강화. DevSecOps 선구자 중 한 명인 드라이런 시큐리티(Dry Run Security)의 창립자이자 CEO 제임스 위켓은, GPT-4 같은 비교적 오래된 모델조차 기존 정적 분석 도구를 능가하는 보안 취약점 탐지 능력을 보일 수 있음을 보여주었다 — 생성형 AI는 패턴 매칭을 넘어 맥락과 의도를 이해하기에 공격으로 이어질 수 있는 미묘한 상호작용까지 식별한다. 이 추측은 2025년 5월 22일, 숀 힐런이 OpenAI o3 모델을 사용해 리눅스 커널의 제로데이 보안 취약점을 발견하면서 사실로 입증되었다 — o3는 대규모 언어 모델을 활용해 사상 최초로 공식 등록된 CVE 보안 취약점을 찾아내는 데 성공했다.
• 가이드라인 자동 집행. 구글의 90페이지짜리 C++ 스타일 가이드처럼 방대한 규칙을 애써 외울 필요가 없다. AI는 코드가 규칙을 준수하는지 스캔하고, 위반 사항에 주석을 달며, 수정을 제안하거나 실제로 수행할 수도 있다 — 풀 리퀘스트 안에서 이런 과정이 이뤄지도록 CI/CD 파이프라인에 구성할 수 있다.
• 지능형 에러 처리. 빌드가 실패했을 때 AI는 복잡한 오류를 해석할 수 있다. CircleCI는 LLM으로 자바 스택 트레이스를 설명해주는 기능을 추가해, 개발자가 난해한 메시지를 직접 해독해야 하는 부담을 줄였다. 이런 기능은 미래엔 에러 로그나 코드 리뷰 코멘트를 기반으로 특정 작업을 자동 처리하는 형태로 진화할 수 있다 — 그렇게 되면 처리가 실패했을 때만 사람을 호출하게 된다.

팀·조직에서 더 많은 사람이 바이브 코딩에 뛰어들기 전에 CI/CD 파이프라인에 더 많이 투자해야 하는 이유가 여기에 있다 — CI/CD에 AI 기반 품질 검사를 더하면 전문 인간 리뷰어가 모든 변경 사항을 분석해주는 것처럼 시스템의 안전성을 크게 높일 수 있고, 프로젝트의 위험은 상당히 줄어든다. AI 기반 리뷰 도구를 설계하는 순간 바이브 코딩을 넘어 AI 엔지니어링의 최전선으로 들어가게 된다 — AI 엔지니어링용 프롬프트는 친구에게 문자 보내듯 가볍게 써선 안 되고, 소송에 휘말린 상태로 상대 측 변호사에게 보낼 문서를 작성하는 것과 같다(이 주제는 칩 후옌의 『AI 엔지니어링』(한빛미디어, 2023)을 추천한다).

마지막으로 짚어야 할 조언 — 생성형 AI를 CI/CD 파이프라인에 접목하는 것은 처음으로 값비싼 외부 서비스를 파이프라인에 추가하는 경험이 될 수 있다. 테스트가 실행될 때마다 10개의 에이전트가 아무 생각 없이 빌드 결과물 전체를 검수하면 무분별하게 토큰을 소모한다. 이를 완화하려면 가능한 더 저렴한 모델을 쓰고, 사전에 정의한 위험 임곗값을 넘는 작업에만 비용이 큰 검사를 실행하게 세팅하며, 이전 분석 결과를 캐싱해두고 변경된 파일만 다시 스캔한다. 이 정도 노력만으로도 재무 팀의 불만을 상당히 달랠 수 있다. 이 절의 기법을 실천하면 시스템은 AI가 문제를 만들어내는 순간 CI/CD 파이프라인에서 그 문제를 사전에 감지하는 능동적인 시스템으로 진화할 수 있다.

12. 교정 — 스티브의 참혹하면서도 장대한 머지 복구 이야기

불운한 사고가 닥쳤을 때는 우선순위를 갖고 명확한 체계로 대응해야 한다 — 먼저 시스템 전반의 병목을 해결하고, 그다음 복구 작업을 수행하며, 마지막으로 재발을 막는 프로세스를 다시 구축한다. 이 절과 다음 절이 다루는 전략은 필요성이 대두되기 전에 미리 몸에 익혀야 한다 — 문제가 생기기 전에 복구 계획을 준비해두라는 뜻이다.

개발자들 사이에는 "우리는 두 종류로 나뉜다 — 이미 깃 관련 사고를 겪은 사람과 앞으로 겪게 될 사람"이라는 오래된 격언이 있다. §10에서 다룬 저장소 전체 유실과는 별개로, 스티브는 대대적인 '깃 수술'이 필요했던 또 다른 사건도 겪었다.

이번엔 파일이 삭제되지는 않았다. 대신 AI 어시스턴트가 중구난방으로 여러 브랜치를 만든 탓에 브랜치를 전환할 때마다 완전히 다른 시대로 가는 것처럼 느껴질 정도였다. 충돌 자체는 500개 파일 중 고작 3개에만 있었는데, 깃은 100개가 넘는 커밋에 대해 동일한 충돌을 반복해서 해결하라고 요구했다 — 끝이 보이지 않는 시간 낭비였다.

스티브는 초반에 AI에게 "이 깃 명령어를 응용해, 그다음엔 저걸 해봐"라고 세부 지시를 내렸지만 시간이 지날수록 오히려 혼란만 커졌다. 스티브는 방향을 바꿔 먼저 명확한 목표를 제시하고 어떻게 할지는 AI에게 재량을 주는 방식으로 전환했다 — "이 브랜치들 완전 엉망이야. 네가 알아서 이 작업을 정리하고 머지까지 제대로 완수해. 더 이상 망가지면 안 돼. 복구 가능하게 작업을 수행해." 저자들은 이를 "잭 오브리 함장식 명령"(목표만 던지고 방법은 맡기는 지휘 스타일)이라 부른다.

AI 에이전트는 세계 최고 수준의 깃 재난 복구 컨설턴트처럼 움직이기 시작했다.

1. 엉망인 브랜치와 main 브랜치 사이 차이가 있는 모든 파일을 식별했다 — 약 500개.
2. 그 500여 개 파일을 별도 영역으로 복사했다.
3. main 브랜치를 기준으로 새 브랜치를 체크아웃했다.
4. 복잡하게 얽힌 히스토리를 우회하기 위해, 방금 만든 깨끗한 브랜치에 500개 파일에 영향을 준 커밋들만 순서대로 하나씩 적용했다 — 사실상 초대형 체리 피킹이었다.

이 작업은 클로드 코드 세션의 콘텍스트 윈도를 약 170%나 소모할 정도로 복잡했다(10장 §2가 설명한 콘텍스트 윈도가 이렇게까지 확장되며 쓰인 사례다) — 스티브가 경험한 가장 긴 바이브 코딩 세션이었다. 작업이 끝났을 때, 고립되어 있던 코드와 가치 있는 기능·수정 사항은 모두 main 브랜치에 성공적으로 병합되어 있었다.

이 구조 작전은 바이브 코딩의 강력한 면모를 보여준다 — AI 파트너는 복잡한 복구 작업에서 매우 값진 전문 인력으로 활약한다(방화를 저지르는 소방관에 비유할 만하다). 이 사례는 FAAFO의 야심·자율성 측면을 극명하게 보여준다 — 어려운 깃 지식이 필요했을 문제에, 스티브는 AI 덕분에 한 명의 개발자론 감당하지 못했을 문제에도 뛰어들 수 있었다.

여기서 얻을 수 있는 교훈은 다음과 같다.

1. 복잡한 문제일수록 프롬프트 수준을 끌어올려라. 표준 절차가 실패했을 때 같은 명령을 반복하지 말고, AI에게 상위 수준의 목표를 준다. AI를 유능한 협업자처럼 대하며 원하는 결과를 설명하고 전략은 AI가 짜게 한다.
2. AI는 비정형적 해결책을 찾아낼 수 있다. AI는 방대한 지식으로, 사람이 막다른 골목에 갇혀 있을 때 떠올리지 못하는 우회로를 생각해낸다.
3. 예방이 여전히 핵심이다. AI가 극적으로 나타나 문제를 해결해준다고 해서 브랜치를 엉망으로 놔둬도 되는 것은 아니다 — §10의 '브랜치 쓰레기 투기' 교훈처럼, 잦은 머지와 브랜치 정리가 이런 악몽을 피하는 가장 좋은 방법이다.

이 사건 이후 스티브는 워크플로에 한 단계를 추가했다 — 바이브 코딩 세션 중 생성된 모든 임시 브랜치를 AI에게 나열하고 삭제까지 확인하라고 주문한 것이다. 진 역시 거의 10년 전 공항에서 실수로 강제 푸시를 해 main 브랜치를 날린 뒤, 어떻게 해야 할지 몰라 친구들에게 도움을 청했던 경험이 있다. 최고의 셰프도 가끔은 요리를 태워먹지만, 동시에 살릴 수 있는 재료는 살려낸다.

13. 끔찍한 프로세스와 아키텍처에 발목이 잡혔을 때

셰프들에게 가장 치명적인 주방은 요리 하나를 내기 전 무려 8개 부서의 승인을 받아야 하는 주방이다. 미 서부에서 가장 빠른 브리게이드 시스템을 갖추고 있어도, 관료주의와 시스템이 발목을 잡는다면 속도는 무용지물이다.

2010년 전후 데브옵스가 등장하며 대부분의 IT 조직은 이 문제에 직면했다 — 변경 사항을 프로덕션에 반영하려면 지정된 사람들의 승인을 받아야 했고, 이 과정은 몇 주씩 걸리기도 했다. 보안에 민감한 변경은 정보 보안 부서의 테스트·승인까지 필요했다. 다행히 데브옵스 선구자들 덕분에 이런 프로세스는 자동화된 프로세스로 대체되었지만, 10년이 지난 지금 저자들은 똑같은 병목이 다시 등장하는 것을 목도하고 있다.

깃랩의 사례. 깃랩의 수석 엔지니어 제시 영은, SOC 2 준수 때문에 변경 사항을 프로덕션에 반영하는 데 여덟 번의 승인이 필요하다면 깃랩은 바이브 코딩의 이점을 얻기 힘들다고 지적했다. AI 어시스턴트가 가져다줄 생산성 10배 증가의 가능성은 전혀 다른 시대를 전제로 설계된 조직 프로세스와 정면으로 충돌한다 — 원활하게 돌아가는 깃랩조차 이런데, 이 문제는 거의 모든 조직을 괴롭힐 것이다.

모건 스탠리의 사례. 모건 스탠리의 전무이사 거스 폴은 이 문제를 직접 해결하러 나섰다. 모건 스탠리에는 1만 5000명이 넘는 기술 인력이 있고 3500개 이상의 애플리케이션이 매년 100억 건의 트랜잭션을 처리한다. 거스는 평균 3.5일 걸리던 변경 승인 시간을 대폭 줄이면서도, 고객 불편을 초래하는 변경의 수는 오히려 줄였다.

거스는 AI가 인간 리뷰어보다 코드 변경 승인에서 더 나은 판단을 할 수 있는지 확인하고자 했다. 그의 팀은 변경의 크기, 자동화 수준, 과거 사고 이력, 시스템의 중요도를 기반으로 머신러닝 모델을 학습시켰다 — 이 모델은 변경 사항이 향후 7일 이내 프로덕션에서 문제를 일으킬지를 놀라울 정도로 정확하게 예측했다. 58개 시스템과 1500건의 변경을 대상으로 한 6개월 파일럿에서, 모델이 승인한 변경은 사고가 단 한 건도 발생하지 않았다(인간 리뷰의 경우 사고율 1.5%). 승인 속도와 치명적 장애 수정 시간도 크게 개선되었다(2주에서 한 시간 이내로 감소).

데이터 사이언스로 수년간의 배포 이력을 분석한 거스의 팀은, 변경 폭이 작고 자동화된 테스트가 잘 갖춰진 배포가 훨씬 더 안전하다는 사실을 입증했다. 이를 바탕으로 프로세스를 재설계해, 위험이 적은 것으로 입증된 일부 배포는 복잡한 승인 절차를 모두 건너뛰고 거의 즉각적인 승인을 받는 "추월 차선"을 만들었다. 모건 스탠리의 사례는 배포 속도를 높이면서도 안전성을 개선할 수 있다는 사실, 통제가 반드시 관료주의를 의미하지는 않는다는 사실을 증명했다.

스티브가 겪은 조직별 스펙트럼. 구글에서는 엔지니어가 빠르게 움직이는 것을 방해하는 프로세스가 거의 없었다 — 강력한 도구·채용 문화·독립적 행동을 장려하는 문화가 결합된 덕분이었다. 아마존에서는 관료주의가 스며들 여지가 일부 있었지만 행동 편향(bias for action)이라는 리더십 원칙 덕분에 사람들의 발목을 잡는 프로세스를 만드는 이들이 설 자리가 없었다. 반대로 스티브가 몸담았던 그랩(Grab)은 빠르게 움직이는 산업군에 있었음에도 VM 하나를 띄우는 것조차 어려울 정도로 뿌리 박힌 IT 관료주의에 시달렸다 — 수십 년간의 전통적 운영 모델에 기반한 내부 프로세스가 변화를 거부해, 시스템을 더 민첩하게 만드는 데 수년이 걸렸다. 이런 투자를 하지 않는 기업에 바이브 코딩을 도입하는 일은 핵심 프로세스와 아키텍처를 재고하도록 강요하는 실존적 위기를 촉발할 수 있다.

다행히 AI 자체가 이런 레거시 문제를 해결하는 강력한 동맹군이 될 수 있다 — 모놀리스를 모듈화하고, 테스트를 개선하고, 워크플로를 자동화하는 데 도움을 준다. 회사에서 AI로 프로덕션용 코드를 작성하는 것이 허용되지 않는다면, 테스트 자동화·모놀리스 해체 전략·CI/CD 효율화에 AI를 쓰는 것을 고려해볼 수 있다. 프로세스·아키텍처 개선에 AI를 투자하는 것은 충분히 가치가 있다 — 조직 차원에서 속도를 제한하는 장치는 제거되어야 하고, 엔지니어들은 최소한 어느 정도는 더 많은 자율성을 갖고 일할 수 있어야 하기 때문이다.

14. 결론 — 외부 루프의 8대 핵심 원칙

이제 바이브 코딩 외부 루프에서 필요한 전략을 실천할 준비가 됐다. 외부 루프에서의 역할은 단순히 손으로 코드를 짜는 개발자를 넘어, AI 주방을 대규모로 지휘하는 비전 있는 아키텍트로 확장된다. 명확한 경계로 '스튜나미'를 예방하는 법, API 계약 보존으로 '다리를 불태우는' 일을 피해야 하는 이유, 버전 관리를 소홀히 했을 때 AI가 '슈거 심포니' 케이크를 통째로 날려버리는 순간, 그리고 거의 희망 없어 보이는 머지 상황에서도 AI가 극적으로 '깃 수술'을 수행할 수 있다는 점까지 살펴봤다.

효과적인 외부 루프 관리란 회복력 있는 시스템을 구축하고, 더 똑똑한 프로세스를 옹호하며, AI로 FAAFO를 달성하는 것이다 — 이것이 이 장이 전하는 가장 중요한 핵심이다.

요리 제국을 확장하며 AI 브리게이드를 지휘하기 위해 기억해야 할 8대 핵심 원칙

1. 아키텍트로서의 역할을 받아들인다. 초·분이 아니라 일·주 단위로 사고하고, AI 어시스턴트들이 효과적이고 안전하게 협업할 시스템을 설계한다.
2. 작업 공간에서 발생하는 '스튜나미'를 예방한다. 디렉터리·저장소·브랜치를 철저히 분리하고 명확히 라벨링해 여러 에이전트가 서로의 영역을 침범하지 않게 한다.
3. API라는 '다리'를 보호한다. 인터페이스를 파괴하지 말고 누적시킨다 — 기존 기능을 깨뜨리는 게 아니라 강화하도록 요구한다.
4. 상황에 맞게 감사를 수행한다. 프로젝트의 위험도와 기술 숙련도에 맞춰, 가벼운 블랙박스 분석부터 강도 높은 화이트박스 분석까지 강도를 조절한다.
5. CI/CD 파이프라인을 강화한다. AI 기반 품질 수문장으로 전환시켜 보안 리뷰·가이드라인 준수 검사·오류 분석을 자동화한다.
6. 깃 규율을 잘 지키게 한다. AI가 원격 저장소에 성실히 푸시하게 하고, 임시 브랜치는 신중하게 검증 후 정리한다. 핵심적인 깃 명령은 직접 손으로 하는 것도 고려한다.
7. 운영 환경에 텔레메트리를 연결한다. AI 에이전트가 시스템 성능을 볼 수 있게 해, 프로덕션 이슈를 탐지·진단하고 수정안을 제안할 수 있게 한다.
8. 프로세스 개혁을 주도한다. AI가 이끄는 생산성 향상이라는 강력한 근거를 활용해, 느리고 관료적인 조직 프로세스에 도전한다.

3부를 시작할 때 저자들은 단순한 전제 하나를 제시했다 — 주방을 불태우지 않고도 고출력의 AI 증강 주방을 운영하는 방법을 보여주겠다는 것이었다. '예방, 감지, 교정'이라는 하나의 리듬을 따라 초·분·시간·날·주, 그리고 그 너머까지 살펴본 결과를 정리하면 다음과 같다.

• 내부 루프(초와 분) — 작게 작업 쪼개기, 끊임없이 테스트하기, 게임 저장하듯 커밋 만들기
• 중간 루프(시간과 날) — 기억용 문신 새기기, 골든 룰 정하기, 멀티에이전트 조율하기
• 외부 루프(주 단위 이상) — API 파괴하지 말기, 초감각 CI/CD 파이프라인, 불필요한 프로세스 제거, 에이전트 함대 관리

이 과정에서 잠든 사이 냉동 창고를 청소해주는 기계(자동화된 백그라운드 정리 작업의 비유), 에이전트에게 새로운 초능력을 부여하는 MCP 서버, 검증의 중요성을 일깨우는 몇 차례의 거대한 주방 화재도 함께 살펴봤다.

4부에서는 개인의 숙련도를 넘어 팀을 강화하는 쪽으로 초점을 옮긴다 — 조직 전반으로 바이브 코딩을 확장하는 방법, 공통의 주방 표준 수립, AI 보조 협업 문화 조성, 그리고 대규모 적용 시 혼돈을 키우지 않으면서 생산성을 높이는 방법을 4부(17장 라인 담당자에서 헤드 셰프로: AI 팀을 지휘하기 · 18장 바이브 코딩 문화 조성하기 · 19장 사람과 AI가 공존하는 개발 팀을 위한 표준 만들기)에서 다룬다.

핵심 개념 정리

실무 체크리스트

• [ ] 지금 만들고 있거나 수정하려는 API가, 이미 다른 서비스·클라이언트가 의존하고 있는 계약은 아닌가?
• [ ] 여러 에이전트가 같은 디렉터리·브랜치·저장소에서 서로 인지하지 못한 채 동시에 작업하고 있지는 않은가?
• [ ] AI에게 새 라이브러리·파일·의존성을 추가하기 전에 "정말 필요한가"를 되묻고 정당화하게 하고 있는가?
• [ ] 프로젝트의 위험도와 내 기술 숙련도를 표 16.1의 매트릭스에 놓아 보고, 그에 맞는 블랙박스·화이트박스 강도를 정했는가?
• [ ] AI가 "모든 변경이 main에 병합됐다"고 말했을 때, 그 말을 그대로 믿고 브랜치를 정리하려 하지는 않는가?
• [ ] AI가 생성한 커밋 메시지가 장황하다는 이유로 대충 훑고 넘어가고 있지는 않은가?
• [ ] CI/CD에 AI 검사를 추가하면서, 모델 비용·임곗값·캐싱 같은 비용 통제 장치 없이 그대로 돌리고 있지는 않은가?
• [ ] 지금 조직의 승인 프로세스가 바이브 코딩의 생산성 이점을 가로막고 있는데도, 데이터로 재설계를 제안해보지 않고 방치하고 있지는 않은가?

연습문제

1. 유형: 판단. 동료가 "AI가 기존 인터페이스를 우회해서 새 기능을 빠르게 완성했다"며 자랑스러워한다. §2·§3의 API 보존 철학(코드 축적 대 코드 파괴)을 근거로 이 접근의 위험을 지적하라.
2. 유형: 분석. 개발자 한 명이 에이전트 2개를 쓰다가 5개로 늘렸는데 생산성이 오히려 떨어졌다고 호소한다. §6의 사례를 근거로 이 현상의 원인과, 스티브가 택한 해결책을 분석하라.
3. 유형: 비교. "저위험·기술을 잘 아는 사분면"과 "고위험·기술을 잘 모르는 사분면"에 필요한 감사 전략을 §7을 근거로 비교하고, 왜 후자가 다층적 접근이 필요한지 설명하라.
4. 유형: 실무 시나리오. AI가 "정리해도 되는 브랜치"라고 제안한 브랜치 12개를 별다른 검증 없이 삭제하려 한다. §10의 여섯 가지 교훈 중 어떤 것을 먼저 적용해야 하는지, 그리고 왜 그런지 판단하라.
5. 유형: 판단. 한 조직이 "AI로 생산성이 10배 오른다니 승인 절차를 없애면 된다"고 성급히 결론 내렸다. §13의 모건 스탠리 사례를 근거로 이 결론이 놓치고 있는 것을 지적하라.

최신 동향 (2026-09 기준)

최신 동향 (검증 2026-09-14) — 이 장이 설명한 예방·감지·교정의 원칙과 사례(API 보존, 워크스페이스 분리, 브랜치 관리, 위험×숙련도 매트릭스)는 그대로 유효하다. 출력 한도 수치 하나와, 저자들의 예측 하나의 실현 여부가 그 뒤로 갱신됐다.

• 출력 콘텍스트 윈도, "4000~8000토큰"에서 자릿수가 달라졌다. 10장 §5는 이 책이 쓰인 시점 기준 "프런티어 모델 대부분은 한 번에 약 4000~8000토큰 정도만 반환할 수 있다"고 적었다. Anthropic 공식 문서에 따르면 이제 여러 최신 모델(Claude Sonnet/Opus 계열)이 응답당 최대 128,000토큰을 출력하며, 배치 처리에서는 별도 베타 헤더로 최대 300,000토큰까지 확장된다 — 이 장이 §12에서 콘텍스트 윈도 "170% 소모"를 이야기할 때 전제했던 출력 규모의 한 자릿수가 달라진 셈이다. 다만 이 장의 핵심 논지(출력 한계 때문에 야심 찬 작업을 더 작은 단위로 쪼개야 한다는 것)는 규모가 커졌을 뿐 원리로는 그대로 유효하다.
• "머지않은 미래에 AI가 자동으로 로그를 스캔하고 PR을 날릴 것"이라는 §9·§11의 예측이 현실화됐다. GitHub 공식 블로그는 에이전트가 대량 생성하는 PR 규모에 맞춘 정책 기반 자동 코드 리뷰, 시크릿 스캐닝의 MCP 연동 등을 2026년 기준 정식 기능으로 소개하고 있고, 여러 팀이 빌드 실패를 감지해 AI 에이전트가 원인을 진단하고 PR을 여는 "셀프힐링 파이프라인" 운영 사례를 보고하고 있다. 이 장이 "몇 년 안에"라고 조심스럽게 표현했던 시나리오가 소수 사례가 아니라 주요 CI/CD 벤더의 정식 로드맵으로 자리 잡았다.

부록 A. 핵심 비교표

부록 B. 추천 참고 자료

외부 자료 (Tier 1 공식, 생존 확인 2026-09-14)

• 코드 생존율 그래프(그림 16.1)의 원 출처 — Rich Hickey, "A History of Clojure", Proceedings of the ACM on Programming Languages (2020)
• o3의 리눅스 커널 제로데이 발견 원문 — Sean Heelan, "How I used o3 to find CVE-2025-37899"
• 콘텍스트·출력 토큰 한도 공식 문서 — Claude 모델 개요 (Claude Platform Docs)
• MCP 공식 사이트 — Model Context Protocol

본 책 연계 챕터

부록 C. 연습문제 풀이

1. (문제 1 정답) §3은 "AI가 기존 동작을 손상시키거나 변경하지 않은 채 코드를 추가하도록 신경 써야 한다"고 명시하며, 이를 클로저·리눅스의 코드 축적 철학에 비유한다. 기존 인터페이스를 우회해 빠르게 완성한 새 기능은 스칼라식 코드 파괴와 같은 결과(오래된 코드·의존 관계의 붕괴)를 부를 수 있다. §2의 진의 사례처럼 "기존 기능은 어떤 것도 깨뜨리면 안 된다"는 원칙과 격리된 공간에서의 실험이 대안이다.
2. (문제 2 정답) §6은 "복잡성은 선형이 아니라 기하급수적으로 증가한다"고 밝히며, 스티브가 2→4 에이전트로 늘렸을 때 조직화 작업이 10배 이상 늘어난 것을 예로 든다. 5개로 늘린 경우도 같은 패턴 — 인지 부하가 폭발적으로 늘어 어떤 에이전트가 무엇을 하는지 추적할 수 없게 된다. 해결책은 스티브의 중앙 지휘소 방식 — 각 에이전트에 고유 역할을 부여하고, 현재 프롬프트·작업 큐·브랜치·상태를 기록하는 전용 추적 문서를 두는 것이다.
3. (문제 3 정답) §7에 따르면 저위험·잘 아는 기술 사분면은 가벼운 화이트박스·블랙박스 테스트만으로 충분하다. 반면 고위험·잘 모르는 기술 사분면은 가장 도전적인 사분면으로, 블랙박스 테스트에 크게 투자(포괄적 테스트 스위트)하는 동시에 상대적으로 가벼운 화이트박스 테스트(명백한 위험 신호 포착)를 병행하고, AI를 코드 리뷰어이자 화이트박스 감사 전문가로 활용해야 한다. 후자가 다층적인 이유는 위험은 높은데 검토자 자신의 언어 지식이 뒷받침되지 않아, 단일 방식만으로는 숨겨진 결함을 잡아낼 수 없기 때문이다.
4. (문제 4 정답) §10의 첫 번째 교훈 "항상 브랜치 의식하기"를 가장 먼저 적용해야 한다 — AI가 지운다고 제안한 브랜치라도, 삭제 전 작업 추적 문서에 그 브랜치가 '완료' 상태로 기록되어 있는지, 그리고 그 제안을 다시 검증했는지 확인해야 한다. 스티브의 사례는 AI의 "모두 병합됐다"는 말을 그대로 믿고 브랜치를 정리하다 일주일 치 작업을 잃을 뻔한 경우였다 — 검증 없이 삭제부터 하면 같은 사고가 재현된다.
5. (문제 5 정답) §13의 모건 스탠리 사례는 "승인 절차를 없앤다"가 아니라 데이터로 위험을 예측해 저위험 변경만 빠른 차선으로 보낸다는 방식을 보여준다 — 58개 시스템·1500건 변경의 6개월 파일럿에서 모델이 승인한 변경은 사고가 0건이었다(인간 리뷰는 1.5%). 승인 절차를 아예 없애는 것이 아니라, 변경의 크기·자동화 수준·과거 이력·시스템 중요도를 근거로 선별적으로 완화하는 것이 핵심이다. 절차 전면 폐지는 이 장이 보여준 증거와 다른 결론이다.